1. Field of the Invention
This invention relates to computer simulation, and particularly to using model-element-proxies to facilitate efficient analysis of simulation results.
2. Description of Background
Computer simulation of processes is widespread. Existing products, such as the WebSphere Business Modeler from IBM, allow users to simulate business processes. In the WebSphere Business Modeler, business process is modeled as a collection of tasks, non-reusable sub-processes, and calls to reusable processes with a defined execution sequence specified by connections and control structures. Each of non-reusable sub-processes may, in turn, contain tasks, other non-reusable sub-processes, and calls to reusable processes. A reusable process can be called from multiple places in the main process, any of the main process' non-reusable sub-processes and any of the main process' called reusable processes.
To further describe process modeling done in WebSphere Business Modeler and similar products, reference is made to FIG. 1 where an exemplary model is depicted. The model includes a process P1 that includes a call to reusable sub-process P0 (later referred to as call-to-P0i). Tasks T1, T2 are implemented in process P1. Process P1 also includes sub-process P2, which includes another call to reusable sub-process P0 (later referred to as call-to-P0j). Tasks T3 and T4 are implemented in sub-process P2. Reusable sub-process P0 includes tasks Tx1, Tx2 and Tx3. Arrows connecting tasks/processes indicate flow of execution.
During simulation, when a given task/process is reached the instance of this task/process is created and then executed. To avoid ambiguity, elements defined in a business process (such as P1, P0, T3, T4, etc.) will be referred to as model-elements (model-tasks, model-processes), while elements created during simulation run will be referred to as element instances (task instances, process instances). Each task and process instance is uniquely identified by its own identifier, and contains a reference (such as model-element identifier) to its model-element.
When model-process P1 is simulated, two process instances of model-sub-process P0 are created (one created through call from P1 instance and one by a call from P2 instance), and corresponding task instances of model-tasks Tx1, Tx2, Tx3 are created in both P0 instances. Let's consider the example aggregated and percolated cost analysis report in Table 1 below. In this analysis each sub-process' cost is an aggregation of costs of all tasks and sub-processes it ultimately contains. In other words, cost is added across a sub-process level and then percolated up the containment hierarchy. It is important to notice there are two rows referring to P0 model-sub-process (as P0i, and P0j), each with an aggregated cost value corresponding to P0 model-sub-process instance owned by a different super-process (which later is referred as P0 in two different contexts). Accurately accounting for the costs of P0 process instances and the associated tasks instances is difficult. The difficulty arises in identifying whether P0 instance was created through a call from P1 instance or from P2 instance. (And similarly, in identifying whether Tx1, Tx2, Tx3 instances were instantiated in P0 process instance resulting from a call issued from P1 or P2 instance.) If aggregated and percolated cost analysis is performed on a single process instance, an algorithm simply traversing a containment tree should give acceptable performance. However, if analogous analysis is to be done for costs aggregated across multiple P1 instances, the traversing algorithm is going to perform very poorly. (Importantly, if RDBMS was to be used to persist simulation results, there is no simple, non-recursive SQL query that could produce the above analysis if for each task/process instance all that is given is its costs, its containment data, and information on its corresponding model-task/process.)
TABLE 1AGGREGATEDPROCESS/COST WITH REUSABLE PROCESSESTASK_NAMECALCULATED IN CALLING CONTEXTP1c_sum(T1) + c_sum(T2) + c_sum(P0i) + c_sum(P2) +c_sum(join) T1c_sum(T1) P0ic_sum(Tx1i) + c_sum(Tx2i) + c_sum(Tx3i) Tx1ic_sum(Tx1i) Tx2ic_sum(Tx2i) Tx3ic_sum(Tx3i) P2c_sum(T3) + c_sum(P0j) + c_sum(T4) T3c_sum(T3) P0jc_sum(Tx1j) + c_sum(Tx2j) + c_sum(Tx3j)  Tx1jc_sum(Tx1j)  Tx2jc_sum(Tx2j)  Tx3jc_sum(Tx3j) T4c_sum(T4) joinc_sum(join)[c_sum(X) = sum of all costs incurred on model-element × instances]
Similarly, execution path identification algorithm that uses only containment and model-element information associated with task/process instances must traverse run-time instance containment tree for each instance of reusable process (or any of its tasks) and thus cannot be very efficient.
Thus, there is a need in the art for a technique to efficiently identify context of task/process instance creation. Among others, this technique must allow for calculation of costs incurred within a reusable process instantiated in any context without the need to traverse main process instance containment tree.